動画配信におけるコンテンツ保護の重要性とそれを実現する仕組みを自分なりにまとめてみた

動画配信におけるコンテンツ保護の重要性とそれを実現する仕組みについて、自分なりにまとめてみました

#AWS Elemental MediaPackage

#AWSメディアサービス

#AWS

大前諒祐

2020.06.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。

今日も今日とて MediaServices な日々を過ごしております。

今回は、動画配信において考慮がほぼ必須となるキーワード、コンテンツ保護 について書いていきたいと思います。

コンテンツ保護とは

そもそも コンテンツ保護 とは何を意味するのでしょうか。

特に明確な定義がある言葉ではないので、私なり考えを述べてみると、

意図したユーザに対してのみコンテンツを配信出来る様にし、コンテンツそのものの価値を下げない事

ではないかと考えています。

逆に、意図しないユーザがコンテンツを見れてしまう様な状態などは、「コンテンツが保護されていない」とも言えると思います。

コンテンツ保護が行われていないと何が起きるのか

では、仮想のワークロードを例にあげつつ、コンテンツ保護が行われていないと何が起きるのか確認してみましょう。

下記に示した構成では、アプリケーション上でユーザの認証を行い、権限のあるユーザのみに動画配信ページを見せているそうです。

一見問題なさそうですが、悪意のあるユーザが存在する場合、認証・認可のレイヤーだけでは防げない様々な事が起こり得ます。

いくつか例をあげてみましょう。

動画ファイルの URL を公開される

アプリケーションは、動画を再生するために動画ファイルが存在するサーバー等に対してリクエストを行ない、動画ファイルを取得しています。

例えば、Web アプリケーション等であればブラウザの検証ツール等を使用する事で、動画ファイルの取得先 URL を簡単に確認する事が出来たりします。

そのため、権限を持つユーザが動画ファイルの URL を取得し公開してしまうと、権限のないユーザであっても動画をダウンロードしたり、視聴できたりする恐れがあります。

通信を傍受され、動画ファイルを取得される

インターネットの世界では当然、通信内容を第三者に取得される可能性もあります。

もし動画配信に関する通信を傍受された場合、本来動画を視聴させたくないユーザにコンテンツを見られてしまう事になります。

スクリーンショットや画面録画等でコンテンツを複製される

特別な知識を持ち合わせていないユーザであっても、動画のスクリーンショットを取得して公開したり、動画の再生画面を録画する事が出来ます。

そうやって複製されたデータを世に公開されてしまうと、本来権限を持ったユーザのみが視聴できるはずのコンテンツは価値が下がってしまいます。

コンテンツ保護を行う為の仕組み

この様に、何も考えずに動画配信を行なってしまうと、悪意のあるユーザによって本来視聴させたくないユーザに動画が配信されてしまい、コンテンツの価値を下げる事に繋がってしまいます。

こういった事を防ぐために世の中には様々な仕組みがあり、それらを使用する事でコンテンツを保護する事が出来る様になります。

以下に、いくつか仕組みを紹介していきます。

Digital Rights Management（デジタル著作権管理、DRM）

「コンテンツ保護といえばコレ」と言えるほどメジャーな仕組みで、音楽や画像、動画などのデジタルコンテンツを保護する為の仕組みです。

基本的な仕組みはコンテンツの暗号化ですが、コンテンツを視聴できる条件をユーザやデバイスで制限したり、有効期限を設定したり、果ては画面キャプチャ等も防ぐ事も可能だったりと、コンテンツを保護する様々な仕組みを実現する事が出来ます。私たちが普段テレビでみているデジタル放送でも、DRM の仕組みが使われていたりします。

また、AWS では AWS Elemental MediaPackage（以下 MediaPackage）が DRM と連携する機能を提供しています。

簡単に仕組みを説明すると、以下になります。

動画配信サーバ（ここでは MediaPackage ）は DRM の鍵管理サーバから払い出された鍵を元に、動画ファイルを暗号化して配信
ユーザの手元に届いた動画ファイルは暗号化されている為、ライセンスサーバーに動画を視聴する為のライセンスをリクエスト
ライセンスサーバー側で認証が行われると、鍵情報などが含まれたライセンス情報がユーザに返却され、動画を再生する事が出来る

仮に、通信を傍受されたり動画の URL を公開されてしまったりしたとしても、ライセンスサーバー側で認証されないとコンテンツの視聴が出来ない為、コンテンツを保護する手段としては非常に強力です。

世の中には様々な DRM プラットフォームが存在しており、代表的なものは以下になります。

HLS + AES

DRM に近い仕組みとして、Apple が開発したストリーミング配信形式である HLS（HTTP Live Streaming）では AES 暗号化という仕組みを使用する事が出来ます。

基本的な仕組みとしては、鍵を用いて動画を事前に暗号化しておき、クライアント側で復号に必要な鍵を取得させ、コンテンツを再生する形になります。

鍵ファイルは、ユーザからアクセスできるサーバやストレージに配置しておきます。

DRM に似た仕組みではありますが、DRM と比較すると以下の弱点があります。

鍵情報が取得されやすい

HLS の AES 暗号化を使用した場合、下記の様にマニフェストファイル（.m3u8等）内に鍵ファイルの取得先が記載されます。

例えば、下記は S3 に鍵ファイルを配置した際に生成されたマニフェストファイルを一部抜粋したものですが、#EXT-X-KEY:METHOD 列の URI 部分に S3 のパスが記載されています。

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:12
#EXT-X-MEDIA-SEQUENCE:9
#EXT-X-KEY:METHOD=AES-128,URI="https://xxxxxxxx.s3-ap-northeast-1.amazonaws.com/hls-aes128/aes128.key",IV=0x00000000000000000000000000000009
#EXTINF:12.00000,
withEncrypt_20200606T172024_00009.ts
#EXT-X-KEY:METHOD=AES-128,URI="https://xxxxxxxx.s3-ap-northeast-1.amazonaws.com/hls-aes128/aes128.key",IV=0x0000000000000000000000000000000A

その為、本来コンテンツを視聴させたくないユーザでなくても鍵ファイルを取得し、動画を視聴出来てしまう可能性があります。

鍵ファイルを格納するサーバやストレージ側で認証の仕組みを取り入れる事である程度は防げるかもしれませんが、DRM と比較するとコンテンツの保護力という面では劣ってしまいます。

あくまで暗号化のみしか出来ない

DRM では、暗号化したコンテンツに視聴可能な時間制限を設定したり、画面キャプチャ等を禁止する事が可能だったりしますが、HLS の AES 暗号化ではあくまでコンテンツを暗号化し、復号出来ない（＝鍵ファイルを取得できない）場合は再生不可能となる方式となります。

※細かい部分では、720p 以下の動画に限り複製が不可になる、等の仕様はある様です。

CloudFront 署名付きURL / 署名付き Cookie

AWS において動画や画像などのコンテンツを配信する場合には、多くのケースで CloudFront を使用するかと思います。

CloudFront では署名付きURL と署名付き Cookie という機能が提供されており、これらを用いる事でコンテンツの保護が可能となります。

署名付き URL と署名付き Cookie を使用してプライベートコンテンツを供給する

細かい仕組みは異なりますが、どちらもコンテンツを取得する為の一時的な URL や Cookie を発行する仕組みです。

これらを認証基盤に組み込む事により、コンテンツを視聴できるユーザを制限する事が可能です。

細かい説明については、先人のブログが沢山ありますので、これらをご参照ください。

コンテンツ保護という観点では、以下のポイントが存在します。

視聴可能時間や IP 等の制限を設定可能な一方で、生成された URL や Cookie が漏れて第三者に使用された場合、設定された条件をクリアしてしまうとコンテンツが視聴できてしまう
コンテンツそのものの暗号化は行わないため、通信を傍受される場合の対策にはならない

どの仕組みを使えば良いのか

他にもコンテンツを保護する為の仕組みは存在するとは思いますが、よく出てくる要素としては上記の 3つかと思います。

「じゃあ、実際に動画配信基盤を構築する時にはどの仕組みを使えば良いの？」という疑問については色んな考え方があるかと思いますが、ここでは自分なりにまとめたものを表にしてみました。

仕組み	導入コスト	コンテンツ保護力	備考
DRM	高	高	コンテンツ保護という観点では理想的
HLS + AES	中	中	HLS でしか使えない
署名付き URL / 署名付き Cookie	中	中	アプリケーションの認証ロジック等に組み込む必要あり